COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.aff: NEWSS AFFIXMENT
C00011 ENDMK
C⊗;
.aff: NEWSS AFFIXMENT

	Assembly often involves affixing  one object to another.  HAL
has a mechanism to automatically keep  track of the location of  a
subsidiary piece of the assembly as its  base is moved; the mechanism
is  called %4affixment%*.   For example, there  might be  a frame called
pump and a  frame called base.   At some stage  in the assembly,  the
pump  is bolted  to the  base.   At this  time it  is appropriate  to
include the statement 
.UNFILL
	AFFIX pump TO base	.
.REFILL
 The  effect of  this is  severalfold: It  informs the compiler  that
motions of base  are to affect the location of pump, it generates the
assertion 
.UNFILL
	ASSERT FACT(AFFIXED, pump, base)
.REFILL
and  it  causes code  to be  generated  for the  runtime which  will
automatically  update the value of  pump every time  base is changed.
Please note  that the  AFFIX statement  does not  act  as a  library
routine invocation; it does not generate code to actually perform the
bolting operation.   The statement merely informs the 'AL system that
at  this stage  in  the  execution of  the  program,  pump is  to  be
considered affixed to base.

	If pump  should be moved while affixed to base, the value of
base itself will not change,  but the affixment will remain  for the
new relative positions of pump  and base.  Occasionally it is desired
that the affixment be symmetric, so that motion of either frame will
cause the other to move.  This is done by including the reserved word
RIGIDLY in the affix statement: 
.UNFILL
	AFFIX pump TO base RIGIDLY
.REFILL
A more precise definition of affixment in terms of graph structures
is given in {sssref  gat}.  Here, we should point out that the
system uses a trans to store the relative positions 
(in our example, (base#α→#pump) ) of the 
affixed frames.  Normally, the system would invent a 
temporary variable to hold this trans; however, the user can 
supply his own variable to be used instead, thus allowing his
to modify the affixment relation directly.  This is done by including
the phrase "BY#<trans#variable#id>" in the AFFIX statement.
For instance,
.UNFILL
	TRANS t1;
	:
	AFFIX pump TO base BY t1;
.REFILL
	If the value of  the trans is modified  in a non-rigid  (that
is,  assymetric)  affixment,  the  effect is to move  the subsidiary
frame.   If  the value  of the  trans  changes in  a rigid  
(symmetric) affixment, then neither frame will change its value until
one of them  explicitly gets a new value; at that time the other will spring
to a new position, as determined by the trans.

The inclusion of the construct "AT#<trans#expression>" will cause
'AL to use the indicated value for the relative affixed position of the
objects.  Thus,

.UNFILL
	AFFIX pump TO base AT NILTRANS

.bull
is equivalent to

	TRANS tempxf;
	AFFIX pump TO base BY tempxf;
	TEMPXF ← NILTRANS
.REFILL
	It  is  possible to  make  chains of  affixments,   possibly
involving some rigid affixments and some non-rigid ones.


Affixments are undone by the UNFIX statement.  For example,
.UNFILL
	UNFIX pump FROM base
.REFILL
will remove the affix structure between pump and base,  and will discard
the invented trans  (unless it was named, of course).  Two changes in
the compiler's assertional data base will also  be generated
(See the section on assertions):

.unfill
	DENY FACT(AFFIXED pump base);
	ASSERT FACT(WAS_AFFIXED pump base)
.REFILL

The latter assertion
is  used in calculation of default  deproach points. A side-effect of
any  assignment,  like "f1#α←#<value>",  is  
.UNFILL
	DENY FACT(WAS_AFFIXED ANYTHING f1);
	DENY FACT(WAS_AFFIXED f1 ANYTHING)     .
.REFILL
.NEWSSS  MOTIONS AND AFFIXMENT

	When some frame has been affixed to an arm, it can be treated
as if it were itself an arm.  Thus, the following is legal and useful:
.UNFILL
	FRAME frob, frobgrasp;
	:
	AFFIX frobgrasp TO frob;
	AFFIX frob TO yellow;
	:
	MOVE frobgrasp TO ⊗ + (Z WRT frob);
.REFILL
The effect of this motion statement is to cause the yellow arm
to move in such a way that frobgrasp moves one centimeter
in frob's Z direction.  The compiler notices that frobgrasp is
affixed to frob, which in turn is affixed to yellow; furthermore,
it knows the relative positions of each of these, so it is not
too hard to translate  the given motion statement into a statement
dealing only with the yellow arm.  It is a great convenience to
let the compiler do this translation, which can get messy in the
presence of complicated affixment structures.

The use of "⊗" inside a motion always refers to the frame being treated
as an arm, whether it is actually an arm (blue, yellow) or an affixed
frame (frobgrasp).

If some frame is attached to more than one arm, then it is not legal
to use this feature, because the compiler would have no way of
determining which arm to use.  Actually, such an attempt is most
likely an error on the user's part; if an object is attahed to
both arms, then they are joined through that object.  It is therefore
not safe to move one arm and not the other.  The "right" thing to
do in such a case would be move all the relevant arms to the appropriate
places.  We do not intend to implement this at first.